The described subject matter relates to network communications. More particularly, the subject matter pertains to arrangements and procedures to negotiate or select negotiable parameters used in the operation of networked components.
Multimedia information includes information that is interpretable by one or more of the five human senses such as sight and hearing. For example, video information is interpreted by the senses of sight and hearing. Audio information is interpreted by the sense of hearing.
There are many different types of systems in which multimedia signals or data are passed in a directed flow from source components (where the signals or data originate or enter the system), through transfer components (which may modify the signals or data), to sink components (where the signals or data terminate or exit the system). A multimedia distribution network is an example of such a system. In a multimedia content and services distribution network, audio and video data might originate from a gateway device (source component), pass through decompression components (transfer components), and be supplied to remote nodes (sink components) for viewing and listening.
FIG. 1 shows an example of a multimedia delivery and presentation system 100 of interconnected components. Functionally, the system retrieves a compressed stream of sampled data representing a video segment from a mass storage device 102, decompresses the data, and displays it on a display device 110. In addition to the two physical devices (mass storage device 102 and display device 110), the system includes a source component 104, a transfer component 106, and a sink component 108. Source component 104 is associated with a device driver 112, in this case a hard disk driver to handle details of communication with the mass storage device 102. The source component 104 retrieves data from the hard disk 102 at appropriate intervals and prepares or formats the data for subsequent handling by the transfer component 106. The transfer component 106 is associated with decompression software 114 for decompressing data into a format suitable for handling by video display hardware. The sink component 108 receives the decompressed data and subsequently associates it with a video display driver 116 for transferring the decompressed data to a video display card and the associated display device 110.
Traditionally, designers of multimedia delivery and presentation systems (e.g., the system of FIG. 1) specify individual components, along with various corresponding operational parameters (e.g., their individual propagation delays), and one or more direct connections between those components. The components, operational parameters, and direct connections are typically specified one at a time, in an arbitrary sequence.
Multimedia data exists in a number of different data formats and various communication protocols are available to transfer such data between networked devices. One issue that needs to be resolved, either by the components themselves or by the component assembly system on behalf of the components, is the format of the data as it is passed from each component to the next. It may be that each component supports a number of different operational parameter combinations such as data formats, communication speeds and/or protocols. However, it will often be the case that the different components do not support the same sets of operational parameters. (Hereinafter xe2x80x9coperational parametersxe2x80x9d in general are often to referred to as xe2x80x9cformat parametersxe2x80x9d).
One way to negotiate format parameters is to allow each connected group of components to negotiate among themselves as they are being connected. In the example of FIG. 1, source component 104 and transfer component 106 would initially negotiate to select an optimum set of format parameters supported by both of the components. Once this connection was completed, the transfer component 106 and sink component 108 would negotiate to select another set of format parameters supported by both of these components. In practice, each component would implement a negotiation interface which would be used to actively arbitrate with other components in determining a common communication format.
While this type of negotiation scheme might work in many situations, it does not always result in the optimum overall parameter selection. In this scheme, parameter decisions are made locally as individual components are connected. However, the most efficient parameter selection between two components may not be the most efficient selection when the entire path is considered.
For instance, it might be in the example of FIG. 1 that source component 104 and transfer component 106 both support a very efficient data format as well as a slightly less efficient data format, while sink component 108 supports only the less efficient format. Based on the scheme described above, the most efficient format would be chosen for the interconnection between source component 104 and transfer component 106. However, this format would not be available for the interconnection between transfer component 106 and sink component 108, so a format conversion would be required to convert the data to the less efficient format for subsequent transfer to sink component 108. In this situation, it would have been more efficient to select the less efficient format for all interconnections, thus avoiding the processing penalty of the format conversion.
In practice, the problem of choosing appropriate or optimum format parameters can become far more complex than indicated by the example of FIG. 1. For instance, each component may have multiple input ports and multiple output ports, each of which might be connected to a different component. In addition, a negotiated parameter selection on one port of a component might impose restrictions on the format parameters available at other ports of the same component. Furthermore, there may be a hierarchy of parameter information, such that making one decision in a negotiation not only affects the choices that can be made for other parameters, but even determines which other parameters are relevant to the negotiation.
Even the task of designing negotiation interfaces is problematic. For instance, it is difficult to define interfaces that effectively support radically different classes of communication formats, since each class may require a substantially different form of negotiation. Furthermore, implementation of a negotiation interface requires a high degree of intelligence in each component, thus impeding the automation of the negotiation process. This requirement for component-level intelligence places a significant burden on the implementer of each component. One mechanism that can be employed to ease this burden is the creation of generic ports, which are component ports that contain all of the basic logic for data exchange and parameter negotiation, yet are not specific to any type of component. These generic ports can be instantiated by the component designer and modified as necessary to support the component""s negotiation needs. However, since the negotiation interface that each port presents is so heavily dependent upon the classes of communication formats that are supported by the port""s component, definition and implementation of generic ports is a difficult problem, and one that has no obvious solution.
It is apparent that the previously proposed methods of negotiating or selecting communication parameters for use among groups of interconnected components have a number of problems. The following subject matter addresses these problems and allows parameters to be selected to provide the optimum overall performance.
In a distributed network of interconnected multimedia source, transfer, and sink components, the described arrangements and procedures defer parameter selection until all relevant information is available. Parameter decisions are made only after all allowable values are known for each component port in light of the specified interconnections between components. Specifically, a parameter set is specified for each port. The parameter set indicates the allowable values for each parameter relevant to the communication formats supported by the component for the port. Each parameter set is expressed as a Boolean expression of constraints. A constraint is expressed as a parameter identifier and a value scope. A value scope comprises a list of allowed single values and of allowed ranges of values.
When ports of components are to be interconnected, the constraints on the parameter sets of the ports are conjoined to form a parameter set intersection. The intersection of the parameter sets is made available to each of the components participating in the connection, who may use the information in the intersection to limit the values of the parameter sets on the participating ports or other ports of the components to reflect parameter interdependencies within a port or among the component""s ports.
As new port interconnections are made, parameter sets of the connected ports are intersected and parameter sets within the interconnected components are appropriately limited. After the components limit their parameter sets, the parameter set intersections are recalculated and further limited based on the recalculations. This process is repeated a number of times until further repetitions result in no further limitations of the various parameter sets.
When all interconnections have been made and the parameter sets have converged through cycles of intersection and limitation, values for the negotiable parameters are selected from the final parameter sets. These values are chosen to yield the most efficient overall system rather than to optimize the system on only a local or port-to-port basis.